There is a growing proliferation of organizational networked computing systems. Every type of organization, be it a commercial company, a university, a bank, a government agency or a hospital, or any other kind of organization, heavily relies on one or more networks interconnecting multiple computing nodes. Failures of the networked computing system of an organization or even of only a portion of it might cause significant damage, up to and including completely shutting down all operations. Additionally, all data of the organization can exist somewhere on its networked computing system, including all confidential data comprising its “crown jewels” such as prices, details of customers, purchase orders, employees' salaries, technical formulas, etc. Loss of such data or leaks of such data to outside unauthorized entities might be disastrous for the organization.
As almost all organizational networks are connected to the Internet at least through one computing node, they are subject to attacks by computer hackers or by hostile adversaries. Quite often the newspapers report incidents in which websites have crashed, sensitive data has been stolen or service to customers has been denied, where the failures were the results of hostile penetration into an organization's networked computing system.
As a result, many organizations invest a lot of efforts and cost in preventive means designed to protect their computing networks against potential threats. There are many defensive products offered in the market claiming to provide protection against one or more known modes of attack, and many organizations arm themselves to the teeth with multiple products of this kind.
However, it is difficult to tell how effective such products really are in achieving their stated goals of blocking hostile attacks, and consequently most CISO's (Computer Information Security Officers) will admit that they don't really know how well they can withstand an attack from a given adversary. The only way to really know how strong and secure a system is, is by trying to attack it as a real adversary would. This is known as red-teaming or penetration testing (pen testing, in short), and is a very common approach that is even required by regulation in some developed countries.
Penetration testing requires highly talented people to man the red team. Those people should be familiar with each and every publicly known vulnerability and attacking method and should also have a very good familiarity with networking techniques and multiple operating systems implementations. Such people are hard to find and therefore many organizations give up establishing their own red teams and resort to hiring external expert consultants for carrying out that role (or completely give up penetration testing). But external consultants are expensive and therefore are typically called in only for brief periods separated by long intervals in which no such testing is done. This makes the penetration testing ineffective as vulnerabilities caused by new attacks that appear almost daily are discovered only months after becoming serious threats to the organization.
Additionally, even well-funded organizations that can afford to hire talented experts as in-house red teams do not achieve good protection. Testing for vulnerabilities of a large network containing many types of computers, operating systems, network routers and other devices is both a very complex and a very tedious process. The process is prone to human errors of missing testing for certain threats or misinterpreting the damages of certain attacks. Also, because a process of full testing against all threats is quite long, the organization might again end with a too long discovery period after a new threat appears.
Because of the above difficulties several vendors are proposing automated penetration testing systems. Such systems automatically discover and report vulnerabilities of a networked system, potential damages that might be caused to the networked system, and potential trajectories of attack that may be employed by an attacker.
Automatic penetration testing systems can be divided into those that are actual-attack penetration testing systems and those that are not. Actual-attack penetration testing systems are characterized by using actual attacks in order to validate that a given vulnerability is indeed applicable to a given network node and is effective in compromising it under current conditions of the node. Such systems do not need to know in advance whether conditions required for the vulnerability to be effective are satisfied. An attempt is made to compromise the given network node using the given vulnerability. If the attempt succeeds in compromising the node then the penetration testing system concludes the vulnerability is effective, and if it fails to compromise the node then the penetration testing system concludes the vulnerability is not effective.
On the other hand, in penetration testing systems that are not actual-attack penetration testing systems the validation of the effectiveness of a given vulnerability to a given network node is judged by collecting factual data about the given node and then evaluating the effectiveness of the vulnerability when applied to the given node according to rules retrieved from a security vulnerabilities knowledge base or according to a simulation. In such systems, unlike in actual-attack penetration testing systems, there is no risk of the penetration test compromising the tested networked system. This difference is of high importance to many organizations and is the reason why those organizations refrain from using actual-attack penetration testing systems.
One important type of security vulnerabilities is the class of macro-based vulnerabilities.
A macro language is a programming language which is embedded inside a software application (e.g., a word processor or a spreadsheet application). The most common reason for using a macro language in an application is for automating frequently repeated sequences of user operations. Typically, a frequently used sequence of user operations can be executed by activating a single key combination previously assigned by a user to trigger the sequence. For example, a user of Microsoft Word may define a macro such that the combination of the Ctrl key and the “B” key will cause the activation of the “bold”, “Italic” and “Underline” modes together. Thus, instead of the user having to manually do three separate operations for activating the three modes, he may issue a single Ctrl+B command, a much more convenient way of achieving the same result.
Some software applications, such as Microsoft Word, Excel and PowerPoint allow macro programs or similar program routines to be embedded in a document such that the macros or program routines are run automatically when the document is opened by the application (for example, “AutoOpen macros” in Microsoft terminology). For example, a user may embed a macro in a Microsoft Word document such that, when the document is opened by any user, the macro executes immediately after the document is opened and adds a log line at the end of the document, indicating the time the document was opened. Similarly, macros can also be defined to be activated when the document is closed. We shall call a macro or similar program routine that is automatically executed when a document in which it is embedded is opened “an auto-executing macro”.
The ability of auto-executing macros to automatically execute pre-programmed sequences of instructions when a document file is opened by a user opens the door for an attacker to cause execution of malicious code in the computer of a user. An attacker can embed a “poisoned” macro within a document file, such that the macro will automatically execute when the file is opened. The attacker then causes the file containing the macro to be imported into the network node of the targeted user whose computer the attacker wants to compromise.
The most common way of achieving this is by sending an email to the targeted user, with the file containing the macro inserted as an attachment into the email. If the receiving user opens the attachment, the poisoned macro code is automatically executed on his computer. The malicious macro code might then delete files, export confidential files to the attacker's computer, copy itself to additional files, or do any other operation desired by the attacker. Thus, auto-executing macros might create security vulnerabilities for a computing device. A security vulnerability of a computing device which requires executing an auto-executing macro by the computing device in order to get the computing device compromised is herein called “a macro-based vulnerability”.
While sending the macro-infected file as an attachment to an email is the most common way used by attackers for causing importing of a macro-infected file into a network node, it is not the only way. An attacker may add the poisoned macro into a file located in a shared folder to which the attacker has write access and the targeted user has read access, hoping the user will open the file. Alternatively, an attacker may store the macro-infected file into a portable storage device such as a USB thumb drive or removable optical media, hoping the user will insert the storage device into his network node and will then open the file. Alternatively, an attacker may cause a transfer of the macro-infected file into the targeted network node through a wireless communication channel such as a Bluetooth channel, again hoping the user will open the file. Regardless of the method used for importing the file, the danger of executing malicious code hidden in an auto-executing macro is real and must be dealt with.
Suppliers of software applications that might be used for generating macro-based security vulnerabilities are aware of the macro-caused dangers and typically provide some safety measures. For example, in Microsoft Word 2016 the user may select a policy regarding executing macros, choosing from (i) Disable all macros without notification, (ii) Disable all macros with notification (the default), (iii) Disable all macros except digitally signed macros, and (iv) Enable all macros. The policy currently in effect is always indicated in the registry.
Under the default policy of “Disable all macros with notification”, when a user opens a file containing an auto-executing macro, a small dialog box is displayed by Microsoft Word below the menu bar and the commands strip (see FIG. 3 for a ‘screenshot’ of a typical Microsoft Word dialog box). The dialog box displays the text message “SECURITY WARNING” in a relatively large font, and to its right the text message “Macros have been disabled.” in a smaller font. To the right of both text messages a button is provided, labeled as “Enable Content”. This dialog box notifies the user about the existence of an auto-executing macro in the opened file and gives him a choice between allowing the macro to run (by pressing the button) and blocking the macro from running (by ignoring the button). FIG. 4 shows an example of a dialog box displayed by a version of Microsoft Excel. With a header of “Microsoft Office Excel Security Notice”, a warning paragraph and an explanatory paragraph, the dialog box offers a choice between two buttons: ‘Enable Macros’ and ‘Disable Macros’.
Other software applications may present the macro choice to the user in other forms, which may be visually different from the Microsoft Word dialog box or the Microsoft Excel dialog box, but provide equivalent functionality. Examples for equivalent forms for presenting the macro choice to the user may be by presenting two mutually-exclusive radio buttons and an “OK” button, two separate buttons, etc. The two options the user chooses from in these examples may be marked by “Allow macro” and “Block macro”, as an example.
For the purpose of this disclosure we refer to all forms of dialog boxes in which a user is prompted to provide his decision regarding allowing or blocking a macro as “macro dialog boxes”. We consider a macro dialog box to be an input mechanism by which the user provides his decision by making a selection between allowing the macro to execute and blocking it, regardless of the way the macro dialog box is implemented and regardless if a question is explicitly presented to the user or is only implied (as in the Microsoft Word macro dialog box).
By their nature, penetration testing systems need to identify security vulnerabilities that can be used by an attacker to compromise the tested networked system. Consequently, penetration testing systems need to find out whether macro-based vulnerabilities are effective in compromising network nodes of a networked system under test.
Macro-based vulnerabilities differ from other types of vulnerabilities in a fundamental way. The effectiveness of most vulnerabilities depends on factual data about the targeted node and the vulnerability—is a given Internet port currently open in the targeted node, was a given patch of the operating system installed in the targeted node, does the targeted node attempt to access a database web server, is the vulnerability applicable to Windows 7, etc.
As an example, a vulnerability may be known to exist in Windows 7, which vulnerability might allow an attacker to steal a password file, provided that Internet port X is open. In order to determine whether a given node might be compromised using that vulnerability, a penetration testing system needs to know (i) whether the given node runs Windows 7, (ii) whether a patch provided by Microsoft to protect against the vulnerability is installed in the given node, and (iii) whether Internet port X is currently open in the given node. In a non-actual-attack penetration testing system, once the reconnaissance function of the penetration testing system collects the above facts, the applicable decision rules associated with the vulnerability are evaluated and a conclusion is reached regarding the success of the vulnerability in compromising the given node.
But for a macro-based vulnerability, there is one more question that needs to be answered before a conclusion is reached—will the user of the targeted node allow or disallow the malicious macro to run. How can a non-actual-attack penetration testing system answer this question, which requires prediction of human behavior?
There are prior art actual-attack penetration testing systems that attempt to answer the above question by sending the targeted node an email containing an auto-executing macro, that when being executed sends a message to the computing device hosting the penetration testing system. This way the penetration testing system can tell if the macro was actually approved to run by the user or not. Once it is determined that the user allowed the executing of the macro during the test, it is concluded that this user is not cautious in his handling of macros and macro-based vulnerabilities would be effective against the targeted node. However, this solution is not applicable for non-actual-attack penetration testing systems, which do not actively send emails to network nodes of the tested networked system.
But even if one would modify the prior art non-actual-attack penetration testing systems to send emails containing documents with auto-executing macros to targeted nodes, this would still not be a satisfactory solution. In the real world, a user may apply judgement when deciding whether to allow or block a macro, and take different decisions under different circumstances. For example, a user may block all macros embedded in documents attached to emails received from outside the organization's networked system, but allow all macros embedded in documents attached to emails received from within the organization.
Therefore, a penetration testing system located outside the organization's networked system that reaches its conclusion by actually sending a file with an auto-executing test macro to a target node may find out the user had blocked the macro and might mistakenly conclude that the targeted node is immune to macro-based attacks, but the correct conclusion might have been that the targeted node is immune to macro-based attacks coming from outside the organization's network. It may well be the case that the user has a practice according to which he does not block macros coming from within the organization's network. Therefore, if another network node of the tested networked system will become compromised and fall under the control of the attacker, then the attacker can send a file containing a malicious auto-executing macro from the compromised node to the target node. In such case the user of the target node will allow the macro to run, as he is trusting all macros received from within his networked system, and the end-result will be the compromising of the target node. Therefore, the prediction made by the above solution according to which the user's response during the test is extrapolated to other scenarios is not reliable and might cause incorrect conclusions by the penetration testing system.
Even if the penetration testing system is located inside the organization's networked system, the conclusion might still be wrong. For example, a user may employ a policy of rejecting all macros, except for those coming from members of his department in the organizations. That is—a QA user may approve macros coming from the QA team, but reject all macros coming from other groups (R&D, Finance, etc.). The penetration testing system may happen to be installed on a node identified as a QA node and therefore any macro it sends to the target node is allowed. It will then conclude that the target node is vulnerable to any macro-based attack. But in reality, any attacker located outside the networked system (or even inside the networked system, but not in the QA group) would fail in compromising the target node using a macro-based vulnerability (unless he is able to compromise another QA node).
Therefore, there is a need for penetration testing systems to reliably predict whether a user of a given network node would block or allow a macro under real-world circumstances.